home *** CD-ROM | disk | FTP | other *** search
- > > I'm not surprised by that but I remember a message from Doug posted in
- > > N.Falcon.Misc long time ago about using that 256 color mode on Falcon. He
- > > said it's possible to write not such slow routines even for 8-bit planes.
- >
- > It's significantly slower though... Maybe the textures etc. could be
-
- It's not significantly slower if you do it right.
- What you do is that you write the image as if you had a real byte per
- pixel graphics mode and then run a chunky to planar conversion on it.
-
- Of course most chunky to planar conversion routines are rather slow, but
- that's not the case with the one I use in MGIFv5 (or the one Doug uses in
- APEXGIF 4.21 [looks slower], but for us the DSP is not available).
-
- Timing by stop watch gives something like 0.8s for a full 640x480 8 bit
- chunky to planar conversion in MGIF.
- For a 160x100 display the conversion time will be:
- 0.8*160*100/(640*480) ~= 0.042s
-
- If we assume that BAD MOOD would run at 10fps in 160x100 with a byte per
- pixel mode, the same thing would be displayed at:
- 1/(1/10+0.042) ~= 7 fps
- in a normal Atari bitplane mode.
-
- That's not bad at all and assumes a computer as slow as the normal
- Falcon030 doing the conversion. The 10fps figure might well be on the
- low side as well for the machines in question.
-
- > converted into Atari's interleaved planar gfx format at load time?
-
- That would most likely not help at all since the graphics are drawn in strips.
- You'd have to do extra reads to mask each pixel written.
-
- > Palette handling would be similar to 8-bit chunky modes I guess...?
-
- Yes, the palette could be handled in exactly the same way as in PC DOOM.
-
- --
- Chalmers University | Why are these | e-mail: rand@cd.chalmers.se
- of Technology | .signatures | johan@rand.thn.htu.se
- | so hard to do | WWW/ftp: rand.thn.htu.se
- Gothenburg, Sweden | well? | (MGIFv5, QLem, BAD MOOD)
-
-